La RAM sube de precio y Proxmox no perdona errores
Si llevas tiempo administrando Proxmox, seguramente recuerdas cuando añadir RAM al host era la solución rápida a casi cualquier problema. Un nodo iba justo, se ampliaba memoria y a otra cosa. Ese escenario ha cambiado. La RAM ha subido de precio y ahora cada giga mal asignado se nota, sobre todo cuando gestionas varios nodos o un clúster que ya va cargado.
En el día a día esto se traduce en situaciones muy concretas, VMs (Máquinas Virtuales) que parecen inofensivas pero nunca bajan de cierto consumo, hosts con swap activo cuando “sobre el papel” no debería pasar, o ese aviso incómodo de que la memoria está al 90% y no sabes muy bien cuál es el verdadero culpable. Y lo peor es que Proxmox no siempre grita cuando algo está mal, simplemente sigue funcionando, hasta que deja de hacerlo.
Ahorrar RAM en Proxmox ya no es solo una cuestión de orden. Es una necesidad práctica, casi económica. Y la buena noticia es que la plataforma ofrece herramientas suficientes para hacerlo bien, siempre que se usen con criterio y algo de experiencia.
Ajustes técnicos dentro de Proxmox para ahorrar RAM
Para empezar a recortar, primero hay que hacer un análisis profundo de tu Infraestructura:
Configuración básica de cada Máquina Virtual
El primer punto que conviene revisar es en la configuración básica de cada VM. Desde la interfaz web, en Hardware -> Memory, es habitual ver cantidades asignadas por costumbre más que por necesidad. Aquí no se trata de bajar números a lo loco, sino de observar antes. Proxmox muestra el consumo real de memoria en tiempo casi real, si una VM con 8 GB rara vez pasa de 3 GB, ahí tienes margen claro para ajustar.
Podemos revisar vía comando el uso de memoria usada por cada VM:
qm list### CONTENEDORESpct listVista más detallada en tiempo real:
pvesh get /nodes/$(hostname)/qemu O directamente desde el sistema (es posible que tengáis que instalarlo desde "apt"):
htopEsto comandos son útiles para detectar swapping o presión de memoria en el host.
Ajustar Memory Ballooning
Una vez detectado ese margen, el siguiente paso lógico es activar Memory Ballooning.
El Memory Ballooning es un mecanismo de gestión de memoria en entornos de virtualización que permite recuperar RAM no utilizada por una máquina virtual y devolverla al host, sin necesidad de apagarla.
En la misma sección de memoria puedes definir una cantidad mínima. Técnicamente, esto permite al host recuperar memoria no utilizada por la VM cuando hace falta. Para que funcione correctamente, dentro del sistema invitado deben estar instalados los drivers adecuados (en Linux suele ser transparente, en Windows necesitas los drivers VirtIO actualizados). No es recomendable habilitarlo en VMs muy sensibles a latencia o con cargas impredecibles, pero en servidores de aplicaciones, servicios auxiliares o entornos de test suele funcionar sin problemas.
Podemos usar comandos también de la siguiente forma:
qm set "VMID" --memory 8192 --balloon 4096Podemos validar su configuración con el siguiente comando:
qm config "VMID" | grep balloonEn Windows, asegúrate de que los drivers VirtIO están instalados.
Driver VirtIO
Otro ajuste clave está en el tipo de máquina y el uso de VirtIO. Asegurarte de que tanto el disco como la red usan controladores VirtIO reduce overhead, y aunque no es un ahorro directo de RAM “visible”, sí mejora la eficiencia general del host, liberando memoria que de otro modo se pierde en emulación. Es uno de esos detalles que se configuran una vez y se olvidan, pero marcan diferencia a largo plazo.
Podemos comprobar tipo de disco:
qm config "VMID" | grep scsiDebería aparecer algo como:
scsi0: local-lvm:vm-100-disk-0
Y el controlador:
qm config "VMID" | grep scsihwResultado recomendado:
scsihw: virtio-scsi-pci
Para forzarlo:
qm set "VMID" --scsihw virtio-scsi-pciUsar Contenedores LXC
Cuando el entorno lo permite, merece la pena revisar si algunas VMs pueden migrar a contenedores LXC. En Proxmox, crear un contenedor es trivial y la diferencia en consumo de RAM frente a una VM completa es notable. Desde Create CT, puedes definir límites de memoria muy ajustados y, a diferencia de muchas VMs, los contenedores suelen respetarlos de forma mucho más predecible. Servicios web simples, tareas batch, monitorización o pequeños demonios encajan perfectamente aquí.
Una de las pautas que podemos utilizar es crear CT desde consola con límites de RAM estrictos:
Cambiar memoria de un contenedor existente:
pct set 200 --memory 768Ver configuración:
pct config 200Vigilar Almacenamiento ZFS
En hosts con ZFS, el ajuste del ARC es prácticamente obligatorio si quieres ahorrar RAM. Adaptive Replacement Cache o ARC es el sistema de caché en memoria RAM de ZFS.
Por defecto, ZFS usará toda la memoria que pueda para caché, lo cual es fantástico para rendimiento, pero peligroso cuando el host también virtualiza mucho. En Proxmox esto se controla editando /etc/modprobe.d/zfs.conf y definiendo el parámetro zfs_arc_max.
No es una decisión que deba tomarse a ciegas, pero limitar el ARC a un valor razonable evita que ZFS compita agresivamente con las VMs. Después de aplicar el cambio, reinicio del host y observación durante unos días.
A nivel consola, podemos limitar ARC en ZFS de la siguiente forma:
Editar configuración
nano /etc/modprobe.d/zfs.conf Añadir, por ejemplo:
options zfs zfs_arc_max=8589934592 (8 GB en bytes)
Aplicar cambios:
update-initramfs -u reboot Ver ARC actual tras reinicio:
arc_summaryEl ARC es una de las grandes fortalezas de ZFS, pero en Proxmox puede volverse un problema si no se controla.
Revisar Overcommit de Memoria
También conviene revisar el overcommit de memoria. Proxmox permite asignar más RAM virtual de la que el host tiene físicamente, y aunque esto puede funcionar, es una estrategia que requiere vigilancia constante. En entornos donde la RAM ha subido de precio, el overcommit mal controlado suele acabar en swapping, y ahí el rendimiento cae en picado. Ajustar el ratio de overcommit y ser conservador suele ser más rentable que exprimir hasta el último mega.
Ver configuración actual:
cat /etc/pve/datacenter.cfg Editar:
nano /etc/pve/datacenter.cfg Ejemplo conservador:
memory: overcommit=0.8Guardar cambios (se aplican automáticamente, sin reinicio).
Hugepages
Un detalle menos comentado es el uso de hugepages. En escenarios concretos, como VMs grandes y estables, pueden mejorar el rendimiento y reducir fragmentación de memoria. No es una solución universal y añade complejidad, pero en hosts muy cargados puede ayudar a que la RAM se use de forma más eficiente.
Normalmente, el kernel gestiona la RAM en páginas de 4 KB. Para que el procesador sepa dónde está cada dato, utiliza una tabla llamada TLB (Translation Lookaside Buffer). El problema es que, cuando tienes máquinas virtuales con mucha RAM (digamos 32 GB o 64 GB), el número de páginas de 4 KB es tan inmenso que la tabla se vuelve gigante. El procesador pierde tiempo buscando en ese "índice" infinito, lo que genera latencia.
Al activar Hugepages, obligas al sistema a usar páginas de 2 MB o incluso 1 GB.
- Menos páginas = Índice más pequeño.
- Índice más pequeño = El procesador encuentra los datos más rápido.
No es para todos los escenarios, ya que si una VM usa Hugepages, la memoria se reserva por completo y Proxmox no puede recuperarla dinámicamente. Es "memoria fija" (algo que se pelea con Ballooning). Así que plantearos Hugepages en ciertos escenarios muy concretos.
Para ver estado actual:
grep Huge /proc/meminfo
Asignar HugePages (ejemplo: 8 GB en páginas de 2 MB):
echo 4096 > /proc/sys/vm/nr_hugepagesPersistente:
nano /etc/sysctl.confAñadir:
vm.nr_hugepages=4096Aplicar:
sysctl -pMonitorización de patrones de uso
Por último, está la parte menos técnica pero igual de importante, revisar patrones de uso. Desde Datacenter -> Metrics o integrando Proxmox con sistemas externos de monitorización, puedes identificar picos reales de memoria. Muchas veces descubres que una VM solo necesita más RAM durante una ventana concreta. Ajustar memoria para ese pico y reducirla el resto del tiempo es perfectamente viable en Proxmox, incluso en caliente en muchos casos.
En resumen, si estás ajustando memoria porque la RAM ha subido de precio, céntrate en estos tres comandos primero:
qm listarc_summaryfree -hCon eso ya sabes dónde se está yendo la memoria de verdad. Todo lo demás viene después.
Ahorrar RAM en Proxmox cuando la memoria ya no es barata
La realidad actual es bastante clara, la RAM ha subido de precio y no parece que vaya a volver a los niveles de hace unos años a corto plazo. Eso cambia la forma en la que diseñamos y mantenemos infraestructuras. En Proxmox, donde la flexibilidad es enorme, esa subida se nota todavía más porque cualquier exceso se multiplica rápidamente.
Ahorrar RAM no significa ir siempre al mínimo, ni convertir cada VM en un experimento de supervivencia. Significa conocer tu entorno, cuestionar configuraciones antiguas y asumir que el “por si acaso” ahora tiene un coste tangible. Ajustar memoria se ha convertido en una tarea continua, casi de mantenimiento preventivo, igual que aplicar parches o revisar backups.
Personalmente, con el paso del tiempo he visto que los entornos más estables no son los que tienen más RAM, sino los que la usan mejor. Donde cada máquina tiene lo que necesita y no mucho más. Donde se entiende qué servicios toleran ajustes dinámicos y cuáles no. Y donde se acepta que observar y reajustar forma parte del trabajo, no es señal de que algo esté mal.
Proxmox sigue siendo una plataforma excelente para exprimir recursos, pero no hace milagros por sí sola. Con la memoria más cara, el verdadero ahorro viene de decisiones conscientes, no de recortes a ciegas. Y cuando eso se hace bien, el clúster no solo aguanta mejor, también se vuelve más predecible, más fácil de escalar y, curiosamente, más tranquilo de administrar.
Fin del Artículo. ¡Cuéntanos algo en los Comentarios!
